home *** CD-ROM | disk | FTP | other *** search
/ Amiga Collections: Amiga Amateur Radio User Group / AARUG UK #81 (199x)(Amiga Amateur Radio User Group UK)(PD)[WB][G4DCV].zip / AARUG UK #81 (199x)(Amiga Amateur Radio User Group UK)(PD)[WB][G4DCV].adf / DisView / RIP < prev    next >
Text File  |  1995-05-17  |  6KB  |  142 lines
  1. ===                                                 DISview [518]
  2. rip
  3. ===
  4.  
  5. _________________________________________________________________
  6. rip accept <incoming_gateway_host>
  7. _________________________________________________________________
  8. Remove the specified gateway from the RIP filter table, allowing
  9. future broadcasts from that gateway to be accepted.
  10.  
  11. >> Example:  rip accept igate.zzz.com
  12.  
  13.  
  14. _________________________________________________________________
  15. rip add <destination_host> <seconds> [<flags>]
  16. _________________________________________________________________
  17. Add an entry to the RIP broadcast table.  The IP routing table
  18. will be sent to <destination_host> at <seconds> intervals.
  19.  
  20. Flags settings:
  21.  1:  include route to self
  22.  2:  split horizon
  23.  4:  triggered update
  24.  
  25. If flags is specified as 1, then "split horizon" processing will
  26. be performed for this destination.  That is, any IP routing table
  27. entries pointing to the interface that will be used to send this
  28. update will be removed from the update.  If split horizon
  29. processing is not specified, then all routing table entries
  30. except those marked "private" will be sent in each update.
  31. (Private entries are never sent in RIP packets).
  32.  
  33. Triggered updates are always done. That is, any change in the
  34. routing table that causes a previously reachable destination to
  35. become unreachable will trigger an update that advertises the
  36. destination with metric 15, defined to mean "infinity".
  37.  
  38. Note that for RIP packets to be sent properly to a broadcast
  39. address, there must exist correct IP routing and ARP table
  40. entries that will first steer the broadcast to the correct
  41. interface and then place the correct link-level broadcast address
  42. (callsign) in the link-level destination field.
  43.  
  44. If a standard IP broadcast address convention is used (e.g.
  45. 128.96.0.0 or 128.96.255.255) then chances are you already have
  46. the necessary IP routing table entry, but unusual subnet or
  47. cluster-addressed networks may require special attention.
  48. However, an 'arp add' command will be required to translate this
  49. address to the appropriate link level broadcast address.
  50.  
  51. For example, for an Ethernet network:
  52.  
  53.     arp add 128.96.0.0 ethernet ff:ff:ff:ff:ff:ff
  54.  
  55.  
  56. >> Example:  rip add gate.zzz.com 900 6
  57.  
  58.  
  59. _________________________________________________________________
  60. rip drop <destination_host>
  61. _________________________________________________________________
  62. Remove an entry from the RIP broadcast table.
  63.  
  64. >> Example:  rip drop gate.zzz.com
  65.  
  66.  
  67. _________________________________________________________________
  68. rip merge [on | off]                                  Default: on
  69. _________________________________________________________________
  70. This flag controls an experimental feature for consolidating
  71. redundant entries in the IP routing table.
  72.  
  73. When rip merging is on, the table is scanned after processing
  74. each RIP update.  An entry is considered redundant if the
  75. target(s) it covers would be routed identically by a less
  76. "specific" entry already in the table.  That is, the target
  77. address(es) specified by the entry in question must also match
  78. the target addresses of the less specific entry and the two
  79. entries must have the same interface and gateway fields.
  80.  
  81. For example, if the routing table contains
  82.  
  83.      Dest    Len Interface  Gateway     Metric P Timer Use
  84.      1.2.3.4  32 ethernet0  128.96.1.2    1    0   0   0
  85.      1.2.3    24 ethernet0  128.96.1.2    1    0   0   0
  86.  
  87. then the first entry would be deleted as redundant since packets
  88. sent to 1.2.3.4 will still be routed correctly by the second
  89. entry.  Note that the relative metrics of the entries are
  90. ignored.
  91.  
  92. >> Example:  rip merge off
  93.  
  94.  
  95. _________________________________________________________________
  96. rip refuse <incoming_gateway_host>
  97. _________________________________________________________________
  98. Refuse to accept RIP updates from the specified gateway by adding
  99. the gateway to the RIP filter table.  It may be later removed
  100. with the 'rip accept' command.
  101.  
  102. >> Example:  rip refuse igate.zzz.com
  103.  
  104.  
  105. _________________________________________________________________
  106. rip request <incoming_gateway_host>
  107. _________________________________________________________________
  108. Send a RIP Request packet to the specified gateway, causing it to
  109. reply with a RIP Response packet containing its routing table.
  110.  
  111. >> Example:  rip request igate.zzz.com
  112.  
  113.  
  114. _________________________________________________________________
  115. rip status
  116. _________________________________________________________________
  117. Display RIP status, including a count of the number of packets
  118. sent and received, the number of requests and responses, the
  119. number of unknown RIP packet types, and the number of refused RIP
  120. updates from hosts in the filter table.
  121.  
  122. A list of the addresses and intervals to which periodic RIP
  123. updates are being sent is also shown, along with the contents of
  124. the filter table.
  125.  
  126.  
  127. _________________________________________________________________
  128. rip trace [0 | 1 | 2]                                  Default: 0
  129. _________________________________________________________________
  130. This variable controls the tracing of incoming and outgoing RIP
  131. packets.
  132.  
  133. Setting it to 0 disables all RIP tracing.
  134.  
  135. A value of 1 causes changes in the routing table to be displayed,
  136. while packets that cause no changes cause no output.
  137.  
  138. Setting the variable to 2 produces maximum output, including
  139. tracing of RIP packets that cause no change in the routing table.
  140.  
  141. >> Example:  rip trace 2
  142.